Add ERC: Tap to Pay #686

amhed · 2024-10-26T01:51:26Z

See https://hackmd.io/VyxIMlk1SvCOpBpS6a_2uA?both for initial commentary on the standard

eip-review-bot · 2024-10-26T01:51:53Z

File `ERCS/erc-7798.md`

Requires 1 more reviewers from @g11tech, @SamWilsn, @xinbenlv

ERCS/erc-_____.md

wilsoncusack · 2024-10-26T11:27:32Z

ERCS/erc-_____.md

+1. The merchant is running an app on their point-of-sale (PoS) system that allows initiating a checkout flow. 
+1. When the customer is done ordering, the merchant goes through the checkout flow up and triggers a payment request. 
+1. The merchant app calls the `requestContactlessPayment` RPC method with the expected payload. 
+1. The merchant's device emits an NFC signal via host card emulation ([HCE](https://developer.android.com/develop/connectivity/nfc/hce)) for the customer’s device to read.


Is this done via the Ethereum provider receiving the above call? So is it assumed the provider needs to be running on device?

wilsoncusack · 2024-10-26T11:28:26Z

ERCS/erc-_____.md

+1. When the customer is done ordering, the merchant goes through the checkout flow up and triggers a payment request. 
+1. The merchant app calls the `requestContactlessPayment` RPC method with the expected payload. 
+1. The merchant's device emits an NFC signal via host card emulation ([HCE](https://developer.android.com/develop/connectivity/nfc/hce)) for the customer’s device to read.
+1. The customer, running their wallet software of choice, reads the NFC signal. The customer’s wallet constructs the necessary transaction(s) to execute the onchain checkout. 


Sorry I don't know much about this, why couldn't we just do a normal eth_sendTransaction or wallet_sendCalls via an NFC channel?

We had some sluggish performance transmitting the NFC message with larger payloads and decided to use a relayer for a shorter URI.

you could still use a relayer by using wallet_sendCalls + something like a nfcRelay capability

wilsoncusack · 2024-10-26T11:29:23Z

ERCS/erc-_____.md

+1. Upon successful onchain execution of these transactions, the checkout is complete.
+
+#### Use Case 2: Peer-to-peer Sends
+1. Alice requests a payment on her wallet app by emitting an NFC signal. The contents of the signal is an EIP-681 URI


I think 681 is possibly over specified on things like gas values. Wonder if we could align on something more minimal.

We're already using 681 heavily on send/receive flows on CB Wallet. We tried leaning into existing standards. What would you suggest could be better?

wilsoncusack · 2024-10-26T11:30:39Z

ERCS/erc-_____.md

+    - 1 means the URI is an EIP-681-compliant payload.
+    - 2 means the URI points to an HTTP relayer, where the response of the relayer is either a JSON object with the transaction data already encoded as a 0x string, or a message for the customer to sign. The customer wallet is responsible for constructing, signing and submitting the transaction/message.
+
+- `uri` represents either the EIP-681-compliant payload or the relayer endpoint to query for the JSON payload. 


I feel like 681 URI is not widely adopted and is mostly useful when you can share a string with someone and not a whole payload.

But here we control the channel so I'm again wondering why not just use existing wallet RPCs to describe what we want.

You're right, it's not widely adopted. Open to any other suggestions 🙏

amhed · 2024-10-26T14:43:40Z

Thanks for the quick review @wilsoncusack ❤️

ERCS/erc-_____.md

Co-authored-by: Andrew B Coathup <[email protected]>

ERCS/erc-_____.md

Co-authored-by: Andrew B Coathup <[email protected]>

amhed · 2024-10-29T18:10:50Z

ERCS/erc-7798.md

+```
+
+##### EIP-712
+```ts


I don't think 712 is available on this repository. What's the proper way to do a relative ref here?

- Some fixes on automated PR feedback - Remove relative links - Adds copyright waiver

lukasrosario · 2024-10-30T12:26:22Z

ERCS/erc-7798.md

+});
+```
+
+### Type 1


are offchain signatures supported for type 1? i dont think it's covered by 681?

No, we covered them with the relayed URI. You can basically pass down any long-form payload / set of batched transactions for EIP-3009 or permit2

lukasrosario · 2024-10-30T12:26:42Z

ERCS/erc-7798.md

+}
+```
+
+**[EIP-712](https://eips.ethereum.org/EIPS/eip-712) Message (offline signature)**


hm i guess sendCalls wouldnt work for getting offchain signatures

lukasrosario · 2024-10-30T14:20:35Z

overall i agree with Wilson's feedback -- feel like it would be cleanest if we could just transmit the usual RPC request over the NFC channel. would be easier for devs to reason about and i think it would be easier to adopt than extending the 1193 provider.

seems like there were issues transmitting larger messages through nfc, and it makes me wonder if that should just be an issue for the provider to resolve if the message is to be transmitted over NFC. that way the app dev can use the same interface as usual, and then the wallet maintainers resolve how to compress & transmit to wallet.

amhed · 2024-10-30T15:52:15Z

seems like there were issues transmitting larger messages through nfc, and it makes me wonder if that should just be an issue for the provider to resolve if the message is to be transmitted over NFC. that way the app dev can use the same interface as usual, and then the wallet maintainers resolve how to compress & transmit to wallet.

When you mention the same interface you mend wallet_sendCalls? And send URIs instead of hashed strings representing txs?

lukasrosario · 2024-11-05T16:02:50Z

When you mention the same interface you mend wallet_sendCalls?
correct

And send URIs instead of hashed strings representing txs?
i dont have as strong of an opinion on how the transaction payloads themselves are structured. in fact, if we keep the developer interface the same and just use a 5792 capability, for example, then we don't even need to impose any kind of constraint on the transaction payload format and can let the provider choose the format as they wish. i suppose the problem then becomes you lose the ability to do offchain signatures. i wonder how much of an issue that would be though

SamWilsn · 2024-12-06T22:20:45Z

ERCS/erc-7798.md

+---
+
+## Abstract
+This ERC defines a standard for contactless payment transactions that can allow for interoperable customer to merchant onchain payments, regardless of the wallets the customer and merchant are using.


The abstract should contain enough detail to give the reader a high-level (but still technical) overview of how your proposal accomplishes its goals.

SamWilsn · 2024-12-06T22:21:22Z

ERCS/erc-7798.md

+- An optional mechanism for relaying large JSON payloads using a backend relayer
+
+
+```mermaid


Our renderer doesn't support mermaid. Please replace it with an image in your assets directory (preferably an SVG.)

SamWilsn · 2024-12-06T22:22:27Z

ERCS/erc-7798.md

+
+#### Use Case 2: Peer-to-peer Sends
+1. Alice requests a payment on her wallet app by emitting an NFC signal. The contents of the signal is an [ERC-681](erc-681.md) URI
+> []will this only work with 681? 681 has limitations, like receiver intent which would be great to solve too.


Suggested change

> []will this only work with 681? 681 has limitations, like receiver intent which would be great to solve too.



If you use HTML-style comments, the linter will make sure you replace them before going into Review.

SamWilsn · 2024-12-06T22:24:19Z

ERCS/erc-7798.md

+### requestContactlessPayment
+The requestContactlessPayment method will be added as a standard method to the [EIP-1193 Ethereum Provider JavaScript API](eip-1193). 
+
+This method takes in two parameters: `type` and `uri`.


I usually recommend including a JSON Schema for any new API endpoints.

github-actions · 2024-12-06T22:37:14Z

The commit b0b33c8 (as a parent of ecbfb71) contains errors.
Please inspect the Run Summary for details.

chris13524 · 2025-02-26T01:46:30Z

ERCS/erc-7798.md

+1. Bob then signs and submits the transaction onchain.
+1. Send flow is complete.
+
+### requestContactlessPayment


Shouldn't this have some prefix e.g. wallet_?

Suggested change

### requestContactlessPayment

### wallet_requestContactlessPayment

chris13524 · 2025-02-26T01:47:18Z

ERCS/erc-7798.md

+  params: { 
+    type: 2,
+    uri: "https://nfcrelay.xyz/paymentTxParams?uuid=1234-abcd-56678",
+    verificationCode: "1234567890"


What is the purpose of verificationCode and why can't its value be included in the uri?

I guess its a token/key that the wallet can use to verify the transaction received by the relayer endpoint is the same as the one send by the merchant

chris13524 · 2025-02-26T01:47:57Z

ERCS/erc-7798.md

+  dappUrl?: string;
+  dappName?: string;


This is a phishing vector. Recommend not including it at all (user knows what they tapped) and wallets should do their own security checks e.g. txn simulation.

chris13524 · 2025-02-26T01:50:24Z

ERCS/erc-7798.md

+**Regular Send**
+```ts
+{
+  payloadType: 'eip681';


What makes this a eip681 payload? The fields don't seem to map to EIP-681 very well.

chris13524 · 2025-02-26T01:53:01Z

ERCS/erc-7798.md

+window.ethereum.request({ 
+  method: 'requestContactlessPayment', 
+  params: { 
+    type: 1,


Suggest using strings for type instead of numbers. Specifically, type here should be erc681 and then for the relay perhaps a separate ERC could be defined for the relay design (and use that ERC number here). This allows easier future expansion to more types of in-NFC payloads and relayers without risking conflicting numbers. (ERC number is the type registry)

chris13524 · 2025-02-26T01:56:25Z

ERCS/erc-7798.md

+  }
+}
+```
+Upon submitting the transaction for the [ERC-681](erc-681.md) and contract call cases, if `rpcProxySubmissionParams` is present, then the transaction hash can be optionally submitted via a POST request to the submission URL. The body of the POST would have the following structure:


Optionally? Why not required?

chris13524 · 2025-02-26T01:59:48Z

ERCS/erc-7798.md

+1. The merchant’s device then transmits the NFC relayer endpoint URI and verification code to the customer via any means
+1. The customer’s device then makes a GET request to the endpoint URI
+
+One of three payloads can be returned from the NFC relayer:


What about a payload type where any arbitrary wallet RPC call can be included? Whether that's eth_sendTransaction or more recent specs such as wallet_sendCalls or wallet_grantPermissions.

rpcProxySubmissionParams could also do with a more general approach: sending the wallet RPC response directly.

ganchoradkov · 2025-02-26T07:58:38Z

Do you think expected error handling should be also included in the specs?
There are many ways something can go wrong before the checkout flow is completed e.g.

wallet not supporting erc-7798
transaction rejected by a node on submit e.g. not enough funds
user manually declining the transaction in the wallet
NFC relayer endpoint unreachable on either device

llbartekll · 2025-02-26T13:28:14Z

ERCS/erc-7798.md

+
+[ERC-681](erc-681.md) URIs were also permitted to enable possible direct peer to peer payments. It’s more likely that they’ll be occurring between two end user wallets rather than between a customer and a merchant, but it would be good to include in the event the dapp only requires a simple send transaction to execute the checkout.
+
+## Security Considerations


NFC isn’t end-to-end encrypted, so I think there’s a potential vulnerability to a relay attack. An adversary intercepts and forwards communication between a user and a merchant, basically extending the NFC range. To mitigate this, wallets should have security precautions like transaction simulation, a trusted merchants list, or spending limits.

amhedcb added 2 commits October 25, 2024 21:48

First draft of ERC-7762

2a53c86

no direct assignment

96d6ac6

amhed requested a review from eip-review-bot as a code owner October 26, 2024 01:51

github-actions bot added c-new s-draft t-erc labels Oct 26, 2024

eip-review-bot added e-consensus e-review labels Oct 26, 2024

eip-review-bot changed the title ~~ERC Proposal: Tap to pay open standard~~ Add ERC: Contactless Crypto Payment Standard Oct 26, 2024

github-actions bot added the w-ci label Oct 26, 2024

wilsoncusack reviewed Oct 26, 2024

View reviewed changes

abcoathup reviewed Oct 28, 2024

View reviewed changes

ERCS/erc-_____.md Outdated Show resolved Hide resolved

abcoathup reviewed Oct 28, 2024

View reviewed changes

ERCS/erc-_____.md Outdated Show resolved Hide resolved

abcoathup reviewed Oct 28, 2024

View reviewed changes

ERCS/erc-_____.md Outdated Show resolved Hide resolved

Title Update

98f6b9d

Co-authored-by: Andrew B Coathup <[email protected]>

eip-review-bot changed the title ~~Add ERC: Contactless Crypto Payment Standard~~ Add ERC: Contactless Payment Oct 28, 2024

Adds authors

1d625b6

abcoathup reviewed Oct 29, 2024

View reviewed changes

ERCS/erc-_____.md Outdated Show resolved Hide resolved

EIP has a number

c498382

Co-authored-by: Andrew B Coathup <[email protected]>

github-actions bot added w-ci and removed w-ci labels Oct 29, 2024

amhed commented Oct 29, 2024

View reviewed changes

github-actions bot removed the w-ci label Oct 29, 2024

Rename file to ERC-7798.md

1374d1a

- Some fixes on automated PR feedback - Remove relative links - Adds copyright waiver

amhed force-pushed the erc-taptopay branch from 4186dbc to 1374d1a Compare October 29, 2024 18:15

rename to tap to pay

768b114

eip-review-bot changed the title ~~Add ERC: Contactless Payment~~ Add ERC: Tap to Pay Oct 29, 2024

EIP-712 external link

bcc7b4c

github-actions bot added the w-ci label Oct 29, 2024

Adds a sequence diagram

62a5e7e

amhed changed the title ~~Add ERC: Tap to Pay~~ ERC-7798: Tap to Pay Oct 29, 2024

github-actions bot added w-ci and removed w-ci labels Oct 29, 2024

eip-review-bot changed the title ~~ERC-7798: Tap to Pay~~ Add ERC: Tap to Pay Oct 30, 2024

lukasrosario reviewed Oct 30, 2024

View reviewed changes

Removing sample code

b0b33c8

amhed changed the title ~~Add ERC: Tap to Pay~~ Add ERC-7798]: Tap to Pay Nov 5, 2024

amhed changed the title ~~Add ERC-7798]: Tap to Pay~~ Add ERC-7798: Tap to Pay Nov 5, 2024

SamWilsn reviewed Dec 6, 2024

View reviewed changes

eip-review-bot changed the title ~~Add ERC-7798: Tap to Pay~~ Add ERC: Tap to Pay Dec 6, 2024

chris13524 reviewed Feb 26, 2025

View reviewed changes

llbartekll reviewed Feb 26, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add ERC: Tap to Pay #686

Add ERC: Tap to Pay #686

amhed commented Oct 26, 2024 •

edited

Loading

eip-review-bot commented Oct 26, 2024 •

edited

Loading

wilsoncusack Oct 26, 2024

amhed Oct 26, 2024

wilsoncusack Oct 26, 2024

amhed Oct 26, 2024

lukasrosario Oct 30, 2024

wilsoncusack Oct 26, 2024

amhed Oct 26, 2024

wilsoncusack Oct 26, 2024

amhed Oct 26, 2024

amhed commented Oct 26, 2024

amhed Oct 29, 2024

lukasrosario Oct 30, 2024

amhed Oct 30, 2024

lukasrosario Oct 30, 2024

lukasrosario commented Oct 30, 2024

amhed commented Oct 30, 2024

lukasrosario commented Nov 5, 2024

SamWilsn Dec 6, 2024

SamWilsn Dec 6, 2024

SamWilsn Dec 6, 2024

SamWilsn Dec 6, 2024

github-actions bot commented Dec 6, 2024

chris13524 Feb 26, 2025

chris13524 Feb 26, 2025

ganchoradkov Feb 26, 2025

chris13524 Feb 26, 2025 •

edited

Loading

chris13524 Feb 26, 2025

chris13524 Feb 26, 2025 •

edited

Loading

chris13524 Feb 26, 2025

chris13524 Feb 26, 2025 •

edited

Loading

ganchoradkov commented Feb 26, 2025

llbartekll Feb 26, 2025

		- An optional mechanism for relaying large JSON payloads using a backend relayer


		```mermaid

	> []will this only work with 681? 681 has limitations, like receiver intent which would be great to solve too.
	<!-- will this only work with 681? 681 has limitations, like receiver intent which would be great to solve too. -->

	### requestContactlessPayment
	### wallet_requestContactlessPayment


		[ERC-681](erc-681.md) URIs were also permitted to enable possible direct peer to peer payments. It’s more likely that they’ll be occurring between two end user wallets rather than between a customer and a merchant, but it would be good to include in the event the dapp only requires a simple send transaction to execute the checkout.

		## Security Considerations

Add ERC: Tap to Pay #686

Are you sure you want to change the base?

Add ERC: Tap to Pay #686

Conversation

amhed commented Oct 26, 2024 • edited Loading

eip-review-bot commented Oct 26, 2024 • edited Loading

File ERCS/erc-7798.md

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amhed commented Oct 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lukasrosario commented Oct 30, 2024

amhed commented Oct 30, 2024

lukasrosario commented Nov 5, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Dec 6, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chris13524 Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chris13524 Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chris13524 Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

ganchoradkov commented Feb 26, 2025

Choose a reason for hiding this comment

amhed commented Oct 26, 2024 •

edited

Loading

eip-review-bot commented Oct 26, 2024 •

edited

Loading

File `ERCS/erc-7798.md`

chris13524 Feb 26, 2025 •

edited

Loading

chris13524 Feb 26, 2025 •

edited

Loading

chris13524 Feb 26, 2025 •

edited

Loading